As television (TV) moves from a one-way distribution service towards providing two-way interactive services to end-users, and from being limited to being distributed only to stationary locations towards being distributable practically anywhere and to services that can be watched on various types and sizes of screens, we are about to witness the birth of an entirely new mass market for TV programming, advertising, interactive games, and different types of interactive services.
Internet Protocol Television (IPTV) offers new revenue opportunities for telecommunication service providers when it comes to attracting new customers to their respective networks, in order to offset declining voice traffic revenues. Work on IPTV is underway in several different contexts, including for example the development presently in progress by Open IPTV Forum, which is specifying an end-to-end platform for supplying multimedia and IPTV services to end-users provided with IPTV enabled User Equipments (UEs) over the Internet, as well as for managed networks having controlled quality-of-service (QoS) performance. A version 1.1 specification of a functional IPTV architecture is available at www.openiptvforum.org, where the described architecture is based on the IP Multimedia Subsystem (IMS) that is specified by the Third Generation Partnership Project (3GPP). A UE can access services offered through an IMS in many different ways, both via wired access, such as e.g. via via Ethernet, a cable modem or a digital subscriber line, or via wireless access, such as e.g. via 3GPP-specified cellular radio, or by using the IEEE 802.11 or IEEE 802.16 standard.
IMS is specified in 3GPP Technical Specification (TS) 23.228 V8.4.0, IP Multimedia Subsystem (IMS) Stage 2 (Release 8), March 2008, and previous versions of TS 23.228. Furthermore, different approaches to IMS-based IPTV are described in M. Cedervall et al., “Open IPTV Forum—Toward an Open IPTV Standard”, Ericsson Review No. 3, pp. 74-78 (2007), and in T. Cagenius et al., “Evolving the TV experience: Anytime, Anywhere, Any Device”, Ericsson Review No. 3, pp. 107-111 (2006).
For a UE, which can be a set-top box (STB) or an entity having integrated STB capabilities, such as e.g. a computer, a TV, PDA, mobile telephone or any other IPTV enabled mobile device to access IPTV services via IMS, the UE registers in a Serving Call Session Control Function (S-CSCF), which is an IMS core node that, in essence, is operating as a SIP server. A typical IMS also includes a number of additional nodes, including a Proxy CSCF (P-CSCF), a Media Gateway Control Function (MGCF), and one or more Border Gateways (BGs), that mediate UEs access to the core nodes, and, through the core nodes, access to media content, residing on one or more media servers.
In a conventional IMS based IPTV network it is possible to perform session modifications, which may include a bandwidth reservation for the sessions that have been setup from a user equipment in order to assure that required services will be provided to the end-users. In this context a session can be a Unicasted session, such as e.g. a Video on Demand session that is delivered via a unicast stream, or a Broadcasted session, that is delivered to tuned-in end users via a multicast stream.
A bandwidth reservation procedure ensures that there are enough network resources in the last mile of the network infrastructure, or in the aggregation network, for an IPTV operator to be able to guarantee an adequate user experience with a minimal risk of disruption of a selected service.
If, for example, two sessions together exceed the amount of bandwidth available to an IP operator over the last mile the packets associated with these two sessions will compete for the available network resources, and, thus, packets of both streams will most likely be discarded, thereby resulting in decreased quality for at least one of the sessions. Once bandwidth has been reserved for one or more sessions it is important that no new session is allowed to have a negative impact on the existing sessions.
FIG. 1 is a signaling scheme according to the prior art, illustrating how a typical IPTV service setup may be executed between a UE 100 and an IPTV Network 102, providing one or more IPTV services to UE 100, via an IMS network, represented by Core Network 101 in the figure.
It is to be understood that, although both the IPTV Network 102 and the IMS network, represented by IMS Core Network 101 typically comprise a plurality of network nodes, for simplicity reasons, each of these networks have been represented by one respective node in FIG. 1.
In two initial steps 1:1 and 1:2, UE 100 registers with IMS core network 101, which responds, typically with a 200 OK message. In subsequent steps 1:3-1:6, UE 100 requests for an IPTV service to be provided from IPTV network 102, via a SIP subscribe. Once this procedure has been completed, typically by UE 100 receiving a 200 OK message from the IMS core network 101, as indicated with step 1:6, UE 100 has been provided with IPTV service data, typically referred to as IPTV service discovery data, including a channel list, which indicates all channels that can be provided from the respective IPTV service provider of IPTV network 102. A typical IPTV service discovery signaling procedure is illustrated with steps 1:7-1:10 in FIG. 1. Once provided with information about the available channels, UE 100 may choose to select a required service. In the present example this is illustrated with a HTTP GET message that is sent from UE 100 to the IPTV network 102 via IMS core network 101 in a step 1:11.
In a subsequent step 1:12, IPTV network 102 responds by providing UE 100 with a list, typically referred to as a linear TV channel list, which, among other IPTV channel related information comprises bandwidth requirement information associated with IPTV channels that are available from IPTV network 102. This information is provided to UE 100 as a TISPAN service package, typically referred to as a Broadcast offering of a Broadcast Discovery record.
A broadcast offering typically comprise a number of elements, or attributes, each of which is carrying different kinds of information about the available IPTV channels. For each channel the broadcast offering may comprise information such as e.g. a DVB Triplet, which enables IPTV channel identification at the UE; a textual identity, which represents a respective IPTV channel name; a service location, which is an instruction on where to find the respective channel, and maximum bit rate, which is an indication of the maximum bit rate that is required for a respective service.
In a next step 1:13, the information provided from the broadcast offering is stored in a memory of UE 100. At this stage an end-user of UE 100 may choose to select a preferred IPTV channel from the channels available in the broadcast offering, typically by activating a remote control, or via another user interface that is associated with UE 100. In a step 1:14, an end-user makes such a selection, and in response to a channel selection UE 100 initiates a bandwidth reservation procedure in order to reserve appropriate bandwidth for the selected channel. In the figure this is illustrated with an invitation, typically referred to as a SIP Invite, that is forwarded to IMS core network 101, as indicated in another step 1:15.
If the required bandwidth is not available, or if the required bandwidth for any other reason cannot be allocated to UE 100 this is notified to UE 100, as indicated with a step 1:16a. In such a situation, the end-user may choose to make another re-try for the same channel, or try to select another channel.
If, however, the bandwidth request is approved with by the IMS network, the bandwidth is reserved to UE 100, as indicated with another step 1:16b. The bandwidth reservation procedure is then completed by informing IPTV network 102 of the allocated bandwidth and by IPTV network 102 confirming that information, as indicated with step 1:17 and subsequent step 1:18, and a confirmation is also executed towards UE 100, as illustrated with step 1:19 and subsequent step 1:20.
With the required bandwidth reserved to UE 100, the requested IPTV service can now be initiated. In the present example this is done by UE 100 transmitting an IGMP Join, to IPTV network 102, as indicated with a step 1.21. As illustrated in the figure, IPTV network 102 responds to such a service request by delivering the chosen IPTV channel to UE 100 via a multicast stream, as indicated with a final step 1:22.
A general problem with bandwidth reservations is how to gain appropriate information on how much bandwidth that will actually be necessary to negotiate for a selected broadcast session. As mentioned above, the broadcast channel information necessary for setting up an IPTV session available from an IPTV operator, which is typically delivered in a Broadcast Offering, may comprise an indication of a maximum bit rate for the respective IPTV channels. Such information has a purpose of ensuring that the adequate bandwidth will be available from the IMS core network 101 once resources have been allocated and an IPTV channel has been selected.
A problem with basing a bandwidth re-negotiation procedure on the maximum bit rate attribute, according to the procedure described above is, however, that the required signaling will cause processing delays which may diminish the user experience for a user that is switching between different channels. Before an end-user can view a selected channel a session modification, which may comprise a bandwidth re-negotiation, has to take place, and, as a consequence from such a bandwidth re-negotiation, the end-user will experience a delay before the channel can actually be viewed.
The problem addressed above is particularly annoying when an end-user is swapping between different channels for which different maximum bit rates have been appointed, before deciding to watch one of the available channels on a more permanent basis. Repeated delays may be very annoying to the end-user, while at the same time, from an operators point of view, there may also be little to be gained by initiating bandwidth re-negotiations immediately in response to a channel switch, initiated by an end-user.
In addition, presently known solutions for performing bandwidth re-negotiations also fail to give the IPTV operator any control whatsoever over the usage of the available bandwidth.